devfandomcom-20200223-history
Talk:UserTags
Translations The script tries to translate itself automatically but it can't do so perfectly. To fully translate it, you will need to provide translations for the following messages: *'Inactive' *'Never Edited' *'New Editor' *'New Account' *'Patroller' *'Rollback' *'Global Bot' Note that the script does support languages that have male/female nouns (e.g. Amministratore male and Amministratrice female in Italian) so you can provide per-gender translations as well if needed. Please specify the language and list the messages in the same order as given above, if there are male/female variants then please separate them with slashes. Example: *'Amministratore' / 'Amministratrice' / 'amministratore/trice' (Male, Female, Gender neutral/unknown) de : inactive: 'Inaktiv' : never edited: 'Keine Bearbeitungen' : new editor: 'Neuer Bearbeiter' / 'Neue Bearbeiterin' / 'Neuer Bearbeiter' : new account: 'Neuer Benutzer' / 'Neue Benutzerin' / 'Neuer Benutzer' : patroller: 'Kontrolleur' / 'Kontrolleurin' / 'Kontrolleur' : rollback: 'Zurücksetzer' / 'Zurücksetzerin' / 'Zurücksetzer' : global bot : 'globaler Bot' : Arkondi (talk) 07:09, September 26, 2012 (UTC) *Added. Thanks. Lunarity 07:25, September 26, 2012 (UTC) Why are some tags overridden and others not? I've noticed that the MediaWiki:User-whatever messages are sometimes overridden and sometimes not. The VSTF, Staff and ones of that ilk —the ones that basically most people shouldn't tinker with —are displaying whatever is the current state of the MediaWiki message. For example: tardis:User:Sarah Manley and tardis:User:Sulfur. However, other messages like MediaWiki:User-identity-box-group-bureaucrat and MediaWiki:User-identity-box-group-sysop are being overriden by this script. Is that intentional? It seems to me like it'd be more logical for either all MediaWiki messages to be overridden or none of them —unless I'm just not understanding an underlying theory at work here. — CzechOut 16:55, September 30, 2012 (UTC) : Those aren't being overridden per se, the mwGroups module fetches the core names of the groups from the server, it's using MediaWiki:group-sysop-member instead of MediaWiki:User-identity-box-group-sysop for those. The Staff/VSTF ones are actually not being touched at all, they're being left exactly as Oasis displayed them which is why they show User-identity-box-group messages. I suppose I can change it to prefer User-identity-box-group in all cases if you think it would make more sense to do that. Lunarity 17:34, September 30, 2012 (UTC) :Okay, I've altered the biases to prefer User-identity-... over group-...-member. Lunarity 18:49, September 30, 2012 (UTC) You may want to change the place where the tags attach I've noticed by looking at our users that have defined a real name that the tags seem to be attaching to .UserProfileMasthead .masthead-info h2. This is somewhat awkward on our wiki, because we don't accept that the h2 should be the Wikia default of display:inline. Some of our users, like tardis:User:Duncs Kinnear-Swift, have very long "real" names, so we use a display:block instead. This makes the tags appear on a separate line after the h2 information, as is the case at tardis:user:Josiah Rowe. It might be a thought to allow end-user definition over where the tags will be placed —a sort of "attachwhere" variable —because tardis would certainly put it inline after the h1, not the h2. — CzechOut 16:55, September 30, 2012 (UTC) : It's actually just appending them to the end of hgroup tag, i.e. after everything. I forgot about the real names thing, I'll have to look into it. Where does Wikia put them in that case? Lunarity 17:41, September 30, 2012 (UTC) :Okay, I am emulating Wikia's tagging correctly but it's not working for you. I'll add a parameter that let's you specify a CSS selector to choose what element to place the things after. Lunarity 17:47, September 30, 2012 (UTC) :I've added a selector parameter, oasisPlaceBefore. Just set it to '> h2' and it should place the tags in the right place for you (including the Staff/VSTF ones). By the way, what did you want to change the Staff/VSTF tags for earlier? Tardis Wiki already has customised messages for User-identity for those. If you want to make the tags into links or add hover tooltips, I could try doing that. I'm reluctant to allow the order to be controlled on them, but I could be convinced otherwise. Lunarity 18:49, September 30, 2012 (UTC) Preferences My preferences module is finished. I need a real demo now. Tell me which of the UserTags settings should be user-configurable and I'll build it. My suggestion would be to add languages and technical skills (JS/CSS/templates) and give the users the option to grade themselves on a scale for every ability they advertise. Interested? If so, anything else I should add? -- pecoes 21:49, September 30, 2012 (UTC) : The module docs are here. The Preferences specific problem you'd have to figure out is that you need to be able to access the user's settings for some other arbitrary user (viewer is a different person from the setter), I'm not clear on if the preferences system actually supports accessing some other user's configuration data. There's also a problem that UserTags is a wiki script, not a user script which means it won't follow the user to the preferences wiki when they click the configure button showing the UI hard. The UserTags specific problem is that tags are inherently static, I'm not sure how you would implement grading except for creating a whole swarm of group/tag pairs, or constructing the tags programmatically as needed; neither is particularly appealing on the customisation or i18n fronts (since localising numbers is really ugly, some languages have 6 different types of plurals). : As far as my scripts go, DisplayClock is probably the best candidate for converting (it already supports live altering of the format string whilst it's running so a live preview customisation UI wouldn't be too hard to do). It's reasonably light but would work as a proof of concept. I'd also like to convert HideRail2, although that is on the back-burner until I ascertain the amount of damage that occurs on Wednesday. Lunarity 22:57, September 30, 2012 (UTC) :: The Preferences specific problem you'd have to figure out is that you need to be able to access the user's settings for some other arbitrary user (viewer is a different person from the setter), I'm not clear on if the preferences system actually supports accessing some other user's configuration data. ::True. I would still have to add that. As long as I make those "foreign" settings read-only there should be not much of a problem though. I could make it so that the preferences of the user whose page is visited are loaded by default. ::Programmatically constructing tags is a bit more complicated, yes, but ask yourselves this: Wouldn't it be cool to see at first sight what languages a user speaks? Or what skills he wants to offer to the community and at what level? You've built a cool library with UserTags. It's time to use it for some cool stuff now! :) ::DisplayClock strikes me as a very bad candidate btw. I cannot see myself changing the positioning of the clock or the time formatting - at least not where DisplayClock is installed as a site script. If it's good enough for the rest of the wiki, it's good enough for me. I'd rather not build an interface I wouldn't use myself. -- pecoes 00:12, October 01, 2012 (UTC) :::Constructing the tags themselves won't be hard, although it does prevent the user from customising them since any attempt to override the text will lose the numbers/whatever. That can be worked around by the module taking configuration options to control the text itself instead of relying on the normal core behaviour to take care of that. I find multilingual string processing is a pain but if you want to do it then UserTags will handle it fine, just make sure to set the male and female parameters if they are relevant to the active UI language. Lunarity 01:58, October 1, 2012 (UTC) Interface design suggestion We need to make a few design choices before we know how difficult the i18n might be... Here's what I'd suggest for the tags: En-4CSS-3 and for the Script Preferences: Actual HTML used: User Tags Languages What languages do you speak and want to be contacted in by other users? Aafrikaans English basic intermediate advanced native speaker Skills Do you have any technical skills you would like to make available to the community? (It's in your own interest not to advertise skills you don't have or don't want to share!) Templates basic intermediate advanced professional CSS basic intermediate advanced professional JavaScript basic intermediate advanced professional pecoes 05:43, October 01, 2012 (UTC) :I looked around a little and a scale of 1 to 5 seems to be common for languages: :1 basic - 2 intermediate - 3 advanced - 4 near native level - 5 native speaker : (I'm a 3.5 btw :) -- pecoes 13:11, October 01, 2012 (UTC) ::Looks good to me, although it should be captioned as the Module name (Something like "Skills — UserTags" rather than just "UserTags" specifically since UserTags is an engine script rather than standalone and the Wiki will need to enable the relevant module in order for this to actually do something. I think alternating row colors would be a good idea as well, if possible, I find long strips of almost identical rows of data tend to wear on my eyes. These stats might also be useful to other scripts written by other people in the future so maybe it'd be better to store them under a fake addon name ("usersskills" or something) so that anyone can access them. ::Do you intend to use those tag colors by default? That could be difficult given the large variety of color schemes across Wikia, plus the script isn't tooled for that, you'd have to do mw.util.addCSS manually, and watch out for the cascade order. Lunarity 14:37, October 1, 2012 (UTC) :::Um. Let's leave graphic design choices aside for the moment. This is more of a conceptual sketch. I'll surely make a change or two... I will probably use the jQuery UI slider instead of radio buttons e.g. :::I'll leave the CSS for the language and skill tags up to you. The only thing I wanted to suggest was the - syntax for the tags' contents. :::Any addon can read any other addon's preferences. I don't plan on building in any security restrictions. At least not for the forseeable future. But, yeah, it might be a good idea to add a shared object that all addons can access without any knowledge of one another. I wouldn't want people to store godknowswhat in the shared section though. That creates a few policy problems. I have to mull that over a little... -- pecoes 15:02, October 01, 2012 (UTC)